❮

fix typos

  • Jump to comment-1
    er@xs4all.nl2022-08-01T18:04:54+00:00
    Recent typos...
    • Jump to comment-1
      john.naylor@enterprisedb.com2022-08-02T05:28:21+00:00
      On Tue, Aug 2, 2022 at 1:05 AM Erik Rijkers <er@xs4all.nl> wrote: > > Recent typos... The part of the sentence inside parentheses is not clear to me, before or after the patch: Dropping an extension causes its component objects, and other explicitly dependent routines (see <xref linkend="sql-alterroutine"/>, - the depends on extension action), to be dropped as well. + that depend on extension action), to be dropped as well. </para> -- John Naylor EDB: http://www.enterprisedb.com
      • Jump to comment-1
        er@xs4all.nl2022-08-02T08:32:15+00:00
        Op 02-08-2022 om 07:28 schreef John Naylor: > > On Tue, Aug 2, 2022 at 1:05 AM Erik Rijkers <er@xs4all.nl > <mailto:er@xs4all.nl>> wrote: > > > > Recent typos... > > The part of the sentence inside parentheses is not clear to me, before > or after the patch: > >     Dropping an extension causes its component objects, and other > explicitly >     dependent routines (see <xref linkend="sql-alterroutine"/>, > -   the depends on extension action), to be dropped as well. > +   that depend on extension action), to be dropped as well. >    </para> > Hm, I see what you mean, I did not notice that earlier and I won't make a guess as to intention. Maybe Bruce can have another look? (commit 5fe2d4c56e) > -- > John Naylor > EDB: http://www.enterprisedb.com <http://www.enterprisedb.com>
        • Jump to comment-1
          robertmhaas@gmail.com2022-08-03T16:41:33+00:00
          On Tue, Aug 2, 2022 at 4:32 AM Erik Rijkers <er@xs4all.nl> wrote: > > The part of the sentence inside parentheses is not clear to me, before > > or after the patch: > > > > Dropping an extension causes its component objects, and other > > explicitly > > dependent routines (see <xref linkend="sql-alterroutine"/>, > > - the depends on extension action), to be dropped as well. > > + that depend on extension action), to be dropped as well. > > </para> > > > > Hm, I see what you mean, I did not notice that earlier and I won't make > a guess as to intention. Maybe Bruce can have another look? (commit > 5fe2d4c56e) I think that it's talking about this (documented) syntax: ALTER ROUTINE name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ] [ NO ] DEPENDS ON EXTENSION extension_name So the change from "depends" to "depend" here is incorrect. Maybe we can say something like: the <literal>DEPENDS ON EXTENSION <replaceable>extension_name</replaceable><literal> action (I haven't tested whether this markup works.) -- Robert Haas EDB: http://www.enterprisedb.com
          • Jump to comment-1
            john.naylor@enterprisedb.com2022-08-04T08:08:59+00:00
            On Wed, Aug 3, 2022 at 11:41 PM Robert Haas <robertmhaas@gmail.com> wrote: > > I think that it's talking about this (documented) syntax: > > ALTER ROUTINE name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ] > [ NO ] DEPENDS ON EXTENSION extension_name > > So the change from "depends" to "depend" here is incorrect. Maybe we > can say something like: > > the <literal>DEPENDS ON EXTENSION > <replaceable>extension_name</replaceable><literal> action > > (I haven't tested whether this markup works.) Makes sense, I'll go make it happen. -- John Naylor EDB: http://www.enterprisedb.com
    • Jump to comment-1
      pryzby@telsasoft.com2022-08-01T18:11:36+00:00
      On Mon, Aug 01, 2022 at 08:04:54PM +0200, Erik Rijkers wrote: > Recent typos... LGTM, thanks. Here are some others I've been sitting on, mostly in .c files. -- Justin
      • Jump to comment-1
        john.naylor@enterprisedb.com2022-08-04T10:21:38+00:00
        On Tue, Aug 2, 2022 at 1:11 AM Justin Pryzby <pryzby@telsasoft.com> wrote: > > On Mon, Aug 01, 2022 at 08:04:54PM +0200, Erik Rijkers wrote: > > Recent typos... > > LGTM, thanks. > > Here are some others I've been sitting on, mostly in .c files. I pushed Robert's suggestion, then pushed the rest of Erik's changes and two of Justin's. For Justin's 0004: --- a/src/backend/replication/logical/origin.c +++ b/src/backend/replication/logical/origin.c @@ -364,7 +364,7 @@ restart: if (nowait) ereport(ERROR, (errcode(ERRCODE_OBJECT_IN_USE), - errmsg("could not drop replication origin with OID %d, in use by PID %d", + errmsg("could not drop replication origin with OID %u, in use by PID %d", RepOriginId is a typedef for uint16, so this can't print the wrong answer, but it is inconsistent with other uses. So it seems we don't need to backpatch this one? For patch 0002, the whitespace issue in the top comment in inval.c, I'm inclined to just change all the out-of-place tabs in a single commit, so we can add that to the list of whitespace commits. -- John Naylor EDB: http://www.enterprisedb.com
        • Jump to comment-1
          tgl@sss.pgh.pa.us2022-08-04T13:41:05+00:00
          John Naylor <john.naylor@enterprisedb.com> writes: > On Tue, Aug 2, 2022 at 1:11 AM Justin Pryzby <pryzby@telsasoft.com> wrote: > ereport(ERROR, > (errcode(ERRCODE_OBJECT_IN_USE), > - errmsg("could not drop replication origin with OID %d, in use by PID %d", > + errmsg("could not drop replication origin with OID %u, in use by PID %d", > RepOriginId is a typedef for uint16, so this can't print the wrong answer, > but it is inconsistent with other uses. So it seems we don't need to > backpatch this one? Um ... if it's int16, then it can't be an OID, so I'd say this message has far worse problems than %d vs %u. It should not use that terminology. regards, tom lane
          • Jump to comment-1
            john.naylor@enterprisedb.com2022-08-05T04:47:23+00:00
            On Thu, Aug 4, 2022 at 8:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > John Naylor <john.naylor@enterprisedb.com> writes: > > RepOriginId is a typedef for uint16, so this can't print the wrong answer, > > but it is inconsistent with other uses. So it seems we don't need to > > backpatch this one? > > Um ... if it's int16, then it can't be an OID, so I'd say this message has > far worse problems than %d vs %u. It should not use that terminology. The catalog has the following. Since it's not a real oid, maybe this column should be rethought? CATALOG(pg_replication_origin,6000,ReplicationOriginRelationId) BKI_SHARED_RELATION { /* * Locally known id that get included into WAL. * * This should never leave the system. * * Needs to fit into an uint16, so we don't waste too much space in WAL * records. For this reason we don't use a normal Oid column here, since * we need to handle allocation of new values manually. */ Oid roident; [...] -- John Naylor EDB: http://www.enterprisedb.com
      • Jump to comment-1
        john.naylor@enterprisedb.com2022-08-02T05:52:53+00:00
        On Tue, Aug 2, 2022 at 1:11 AM Justin Pryzby <pryzby@telsasoft.com> wrote: > > Here are some others I've been sitting on, mostly in .c files. 0002: weird since c91560defc57f89f7e88632ea14ae77b5cec78ee It was weird long before that, maybe we should instead change most of those tabs in the top comment to single space, as is customary? The rest LGTM. -- John Naylor EDB: http://www.enterprisedb.com